Conversation
Show users how to chain filecoin-project/filecoin-pin/upload-action after this action to archive the same CAR to Filecoin, without repacking or CID drift. Depends on the upstream change that treats a `.car` `path` as a pre-built CAR (filecoin-project/filecoin-pin#410).
lidel
added
need/community-input
|
Hi @lidel - thanks for investigating... Some context: the filecoin-project/filecoin-pin repo has various affordances for using Filecoin Onchain Cloud with an IPFS point of view. The CLI is the main one we use (with underlying JS library) and promote. The filecoin-pin upload-action was intended to be illustrative of how you can use filecoin-pin in an upload action if you want and what a more polished upload action could look like. I see though now that the extra "polish" is actually getting in the way of making it clear that only a simple CLI command is needed. Obviously please do what you think is right for the ipfs-upload-action. I want to comment on a couple of things:
filecoin-pin has this as well. We can work through additional argument options, but assuming someone has setup a wallet,
Those are the permissions that the example https://github.com/filecoin-project/filecoin-pin/tree/master/upload-action are using. The
Yes, that is valid for the filecoin-pin upload action itself, but not for the filecoin-pin CLI. I see no alpha churn concerns on the
@rvagg: please feel free to jump in if there's anything you think I've missed or am wrong on. |
2 participants
Important
do not merge, opening to illustrate how we can keep filecoin-pin details separate, without any maintenance burden.
What
Adds a
Archiving to FilecoinREADME section showing how to chainfilecoin-project/filecoin-pin/upload-actionafter this action so the same CAR is archived to Filecoin. Noaction.ymlchanges.Why composition, not embedding
I prototyped embedding Filecoin Pin as a first-class provider and it does not look feasible in current state of upstream code:
action.yml. Filecoin Pin is ~400 lines of Node.js (Synapse, USDFC top-ups, PDP, IPNI, retry). Not sane. We could revisit if upstream provides better CLI tooling that blackboxes process end-to-end.checks: write,pull-requests: write,actions: readfor its own check run / PR comment / artifact cache. Every caller would have to grant those, even if they never enable Filecoin. Not feasible, bad opsec.Composition (this PR) scopes all four to users who actually opt in.
Today vs. after upstream #410
Example works today, but upstream repacks the CAR so the Filecoin CID will differ from ours. Once filecoin-project/filecoin-pin#410 ships, switching to
path: build.carmakes the CIDs identical.Revisit when
Filecoin Pin ships a shell-level one-liner comparable to
ipfs pin remote add(Pinata) oraws s3 cp --metadata 'import=car'(Filebase). Then embedding becomes cheap and the argument flips.